User loginNavigation |
LtU Forum, Site DiscussionAvionics Control Systems DSL from 1994, by Doug Lea
Well, the author called it Design Patterns for Avionics Control Systems, but IMO the paper can be seen as a plan for a DSL.
The following quote captured my attention: Thus, no single option is always best or even attainable. Moreover, each can pose problems. For example, pull protocols cannot deal with unexpected or prioritized events. Push protocols cannot always be buffered effectively, and require the existence or development of scheduling policies and algorithms. Shared memory requires the overhead of synchronization to avoid storage inconsistencies.Sounds like a discussion of concurrency models, right? Not the same wording as in CTM, but still. New extension for the TXL language : ETXLWhat is TXL ? What is ETXL ? http://www.cs.queensu.ca/home/thurston/etxl/ For a general view of TXL Adrian Thurston's Master's Thesis In a few words, it simply rocks ! Basic(er) Simple(r) Type Theory(?)My lurking here at LtU has motivated me to learn about type theory, so I picked up a cheap used copy of Hindley's _Basic Simple Type Theory_, and have found myself woefully unprepared for it. A lunchtime sojourn to wikipedia yesterday was my first introduction to S & K combinators, so needless to say, all the formal logic, proofs, etc., are right over my head. Is there a more basic, simpler introduction to type theory that doesn't assume a competant formal background that y'all can recommend, or, failing that, can y'all recommend a list of preparatory works to read first? thanks in advance, JimDesu Today's Status of Functional Programming Languages for Verification Tools ?
An interesting conclusion based on the ML and Haskell implementations existing in October, 2002 comes from the paper
"Functional Programming Languages for Verification Tools: A Comparison of ML and Haskell", by Perdita Stevens with Martin Leucker, Thomas Noll, Michael Weber
[quote] 6 Conclusion There have been positive and negative aspects to both our sets of experiences with Haskell and ML, as there would doubtless have been with whatever language we had chosen. Overall, we consider Standard ML to be a slightly better choice for our kind of application than Haskell, more because of a more stable environment of supporting tools than because of language features. Of course, there are many alternatives including other functional languages of which we have less experience; O'Caml might be a strong candidate. However, it turned out in our discussions that none of us were enthusiastic about the idea of using a functional language for a fu- ture verification tool, because of their impoverished envi- ronments compared with mainstream programming lan- guages. Our conclusion is that if/when we develop new verification tools, these will be written in \a Java-ready subset of C++". That is, we would prefer to be writ- ing in Java, but at present this appears premature for performance reasons. We would write therefore in C++, trying to avoid using features (such as multiple inheri- tance, non-virtual functions, \friends") which cannot be readily translated into Java. [/quote]What would be a conclusion of such a comparison today? Also interesting and very true observation from the same article: [quote] Why is there so little material to help developers make an informed choice? Part of the reason must be that it is very hard to do convincing comparisons of lan- guages without being vulnerable to the criticism that one is not comparing like with like. We think that a fair comparison needs to be based on real experience of peo- ple using the languages to build real systems in the same domain; otherwise it is almost impossible to be sure that diferences are not due to diferences in the domains of application. The systems themselves need to be broadly comparable in size and complexity, need to be more than toys, and should preferably have been developed and maintained over years (since a language that makes de- velopment easy might nevertheless encourage the devel- opment of code which is unmaintainable). Moreover, the domain should be one where either of the languages is a reasonable choice, and the comparison should be done by people with a reasonably typical level of experience in the languages. A comparison is probably most generally useful to developers when it is done neither by novices in the languages compared nor by people intimately fa- miliar with the compiler internals. [/quote]more from the same author... 2005 ICFP Programming Contest
Think your favorite programming language is the best one out
there? Put it to the test in this year's International Conference on Functional Programming's annual Programming Contest. The contest is coming up in a little under 4 weeks and we have just released more information (including a live cd, mailing list, and prize details) to the web page, at: http://icfpc.plt-scheme.org/ This year's competition rewards programmers who can plan ahead. As before, we'll announce a problem and give you three days to solve it. Two weeks later, we'll announce a change to the problem specification and give you one day to adapt your program to the new spec. And you guessed it: the second half will be worth considerably more than the first. Important dates:
ICFP Contest Organizers icfpc@plt-scheme.org By robby at 2005-05-30 18:05 | LtU Forum | login or register to post comments | other blogs | 7093 reads
What is so bad about compiling?No we haven’t lost our mind! We know that compilers and the languages they represent are the absolute foundation of computing. Compilers are so basic and originate so early in the history of computers it is easy to forget what a compiled language really is: A compiled language is simply an extension of the machine codes defining the register machine. As long as we insist that a language compile we are insisting that the register machine must be our computing architecture. This is because no matter how we disguise it the basic properties of the register machine will leak through into any language that must compile directly without an intervening virtual machine. The property we are most concerned about is “flowâ€. We read and execute one instruction after another in order. If we need to execute a different string of instructions we use conditional jump instructions. On a higher level a conditional jump would be a goto statement with a label. Goto’s are very powerful but may lead to what we used to call “spaghetti codeâ€. It can be impossible to “see†where the program is going next. We bring this up because “spaghetti code†still lives in the form of if/then/else statements, but is more subtle. Another example of the “flow†problem is that the code must be analytic. The register machine has no built in way to back up or recover from errors. We can and must check for errors but the only option then is usually to terminate the program. The logic has been broken! The analytic assumption is reasonable as long as the program is not connected to the external world somehow, perhaps through user inputs, sockets, or external activity. The need to be analytic leads the “fortress†mentality; radical steps to ensure that the code is analytic. A solution exists that we like to call synthetic logic. A synthetic logic is a set of event rules with a works or doesn’t work logic. Synthetic logic is a logic of possibility; the event X is said to work if events A, B, and C work in order. If something goes wrong the system simply backs up to the starting point automatically without any specific error processing. Synthetic logic can work along with an analytic true or false logic. The dilemma is that synthetic logic in whatever form will require a virtual machine to execute because it will be based on backward or forward chaining control. In other words it won’t compile on a register machine. It seems to us that language designers must address the larger problem of languages that are hard to compile or impossible to compile. These languages usually don’t make it into prime time because they don’t compile. If we continue to insist that mainstream languages compile we will simply be getting more of the same subtle problems. In the search for the ultimate language the compiler should not be a consideration. Any language concept can be implemented as a virtual machine. With the fast computers that we have today this may be all that is needed. If that language should actually turn out to be the ultimate language then there would be plenty of money to design a machine on which it could be compiled directly. Conference in VancouverSome of you might be interested in the following Conference during the first weekend in June at UBC in Vancouver, Canada: Conference: Foundational Methods in Computer Science (FMCS05) Local organizer: John MacDonald Friday, June 3, 2005 9:00-10:30a.m. Ernie Manes, UMass Amherst, USA 11:00-12:30p.m. Vaughan Pratt, Stanford University, USA 2:30-4:00p.m. Steve Bloom, Stevens Institute of Technology, USA 4:30-6:00p.m. Robin Cockett, University of Calgary Saturday, June 4, 2005 9:00-9:50a.m. Paul Taylor, Manchester, UK 9:50-10:30a.m. Cyrus Nourani, USA 11:00-11:30a.m TBA 11:30-12:15p.m. Art Stone, Vancouver, Canada 2:00-2:30p.m. Varmo Vene, University of Tartu, Estonia 2:30-3:00p.m. Bob Rosebrugh, Mt. Allison University 3:00-3:30p.m. Chris Dutchyn, University of British Columbia 4:00-5:00p.m. Philip Mulry, Colgate University, USA Sunday, June 5, 2005 9:00- 9:30a.m. Brian Redmond, University of Ottawa, 9:30-10:00a.m. X. Guo, University of Calgary, 10:00-10:30a.m. Dana Harrington, University of Calgary 10:30-11:00a.m. Break 11:00-11:30a.m. David Oury, McGill University, 11:30-12:00 Pieter Hofstra, University of Ottawa, 12:00-12:30p.m. TBA Last updated: 5/27/05 For further information see the conference website: Pure bigraphs: structure and dynamics (by Robin Milner)I just came accross this interesting paper: Pure bigraphs: structure and dynamics. From the abstract: "...it is shown that behavioural analysis for Petri nets, pi-calculus and mobile ambients can all be recovered in the uniform framework of bigraphs."
An interesting thing from my point of view is that an attempt is made to provide a descriptive explanation of the material, obviously along with math proofs. Short examples of complex use of state?Hi, I'm looking for some short algorithms that use state in tricky ways, where by "tricky" I mean: 1. State is used nonlinearly. That is, there should be multiple pointers to some of the state in the program. 2. The state should be "visible" to clients. Something like memoizing or caching is stateful and nonlinear, but it has no visible side-effects. 3. The state should have an indefinite lifetime -- that is, stack allocation isn't a sufficient memory management strategy. 4. Ideally, the state should be higher-order -- I'd like to see references of function (or object) types, so that there's a pointer to code. This is less critical than the others, but still nice. Any ideas? I've thought of union-find, and I would guess there are graph algorithms that have these properties, but I'm relatively ignorant about them. Data flow analysis on functional LanguageHi everyone, I need to perform a data flow analysis on a lamda-calculus like functional language. Ideally, this should be a type-based approach. Can anyone on this forum direct me a mean to do this. What is particularly troublesome is that a data flow analysis naturally necessitates a fix-point analysis which is done recursively on the structure of the program whereas a type analysis is done in one pass over the program. I would be grateful for any insight anyone might have to help me solve this problem. R.K. |
Browse archives
Active forum topics |
Recent comments
9 weeks 1 day ago
9 weeks 1 day ago
9 weeks 1 day ago
9 weeks 2 days ago
9 weeks 5 days ago
9 weeks 5 days ago
9 weeks 6 days ago
10 weeks 1 hour ago
10 weeks 2 hours ago
10 weeks 2 hours ago